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METHOD AND SYSTEM FOR USER MODELLING 

Field of the invention 

The present invention pertains to user modeling and personalization in 
5 media delivery networks such as the Internet and was developed by paying 
specific attention to improving operation of user modeling servers included in 
these networks. 

Description of the related art 

10 The provision of personalized services in media delivery networks is 

generally based on the utilization of user modeling systems that collect 
information about users' preferences, skJlls r habits, needs or any other 
information that might contribute to. realize a detailed picture of the individual 
users accessing the service. For instance, in e-commerce applications, the 

15 personalized recommendation of items enables services to suggest the most 
convenient solution for the customer, by considering his/her needs, constraints 
and interests. The recommendation of items can be coupled with a personalized 
presentation of information about products and services in order to provide 
customized presentations and enhance the quality of electronic catalogues, as 

20 well as their accessibility to users with special needs. 

User modeling often employs explicit modeling where users are 
questioned on their preferences before (and also while) interacting with the 
system. Alternatively, implicit modeling can be used to obtain user preferences 
through observation of user activities as they interact with the system. The 
25 capability of modeling a user enables an application to automatically adapt - i.e. 
personalize - their information and services to different user needs, preferences 
or habits. 

Although various personalized services employ different preference 
acquisition and item recommendation techniques (e.g., content-based vs. 
30 collaborative filtering), they usually embed a specific user modeling module. The 
user modeling module is responsible for managing the acquisition of user 
information and for modeling either clusters of users or individual users. The user 
modeling module is employed as an inference engine within the application 
offering the personalized service. 
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The open environment characterizing interaction over geographical webs 
such as the Internet have facilitated the development of User Modeling Servers, 
hereafter refenred also to as UMSs, offering user modeling facilities to more than 
one application. In this scenario, different applications rely on the same UMS, 
5 making possible the reusing of user model information across applications. 

In other words, a user modeling server (UMS) is a centralized system to 
which applications (as provided by content providers, services, web-sites, e- 
commerce actors, etc.) can delegate the user modeling function. 

In a simplified schematization of that function, applications provide data 

0 (generally in the form of usage data) to a UMS and request an estimation of e.g. 
user preferences, needs, and habits. Using a UMS common to more than one 
application may reduce the complexity of an application because the user 
modeling function is used rather than implemented within the application. 
Employing a UMS common to more than one application may be desirable as it 

5 enables the construction of more complete user models, including cross- 
application and cross-domain modeling (i.e. the user preference for a given 
domain/application can Influence the user preferences for other 
domains/applications). 

User Modeling Servers supporting the collection of information about the 

0 user and providing inferential capabilities for the estimation of the user's skills 
and preferences have been developed in the tutoring area e.g. by means of a 
learner modeling server providing multiple (software) teaching agents with 
information about the user's knowledge. In this scenario, the applications 
generally cooperate with one another to the creation of a rich student model to be 

15 utilized for the personalization of the lectures and courses. 

In "One for All an All for One: A learner modelling server in multi-agent 
platform 0 by Machado I et al., published in User Modelling Proceedings of the 
Seventh International Conference UM'99 f p. 211, a learner modeling server that 
can be used by several applications (composed by several agents) is described. 

\0 The server keeps one single database for all the learners being modeled by all 
agents, allowing different applications to access the same learner model 
simultaneously. 

In "Personls: A Server for User Models? by Kay, J. et al., published in 
Proceedings of AH 2002, Lecture Notes in Computer Science 2347, pp. 203-212, 
\5 a user model server is described that can support reuse of the user models over 
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a series of adaptive hypertext systems. The Personis server allows the user to 
define which applications are allowed to see each part of the user model. The 
user can also control the information sources that should be made available to 
each application. An element of the Personis UMS is the "resolver" (a software 

5 module) that is used to interpret the evidence available to it. Specialized 
resolvers can be associated with an application; one client adaptive hypertext 
system might use one resolver. 

Applicants have noted that this prior art arrangement is based on an 
essentially static model, wherein an application selects in a fixed, non- 

0 configurable way those applications that will have to be taken into account by its 
own resolver. Consequently, such an arrangement is not suitable in scenarios 
where the commercial actors providing applications are different and often in 
competition. 

US patent application No. 2002/0199004 discloses a method and a 

5 computer apparatus for establishing a global interest profile of a user. The global 
user profile can be compiled anonymously from local user profiles generated by 
the local servers. Items of information, such as click stream data, collected in 
respect of a plurality of users having visited a plurality of web pages, can be 
processed in a common enterprise server in order to calculate an interest score 

0 for given interest categories (subjects, topics, concrete or abstract concepts). 

US 2002/0013827 discloses a personal service environment manager 
host that manages functionality shared among applications. A common user 
profile directory provides a single point of access to user-related data in the 
network. User-related data are accessible through standard interfaces, which are 

5 administered by operators, applications and end-users via the personal service 
environment manager. 

Additionally, WO 01/0086494 discloses so-called user-specific software 
agents that store user profile data. Each user is provided with a profile agent in a 
multi-service context. A service application can access user data only by means 

0 of a contract associating a certain information concerning the user with certain 
services. The privacy of the user is said to have a central position in the system, 
since the user profile is centralized with an agent that can be controlled by the 
user. 
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Object and summary of the invention 

Applicants have observed that uncond itional sharing of the usage data 
among different applications may not be accepted for an application. This is 
5 particularly true in open and business environments that usually require a third- 
party to provide UMS service to applications owned by different actors, possibly 
in mutual competition. 

Applicants have realized that usage data and any other type of feedback 
provided by an application about its users and their behaviors and exchanged 
10 with other applications have a high practical value: a key player, as the owner of 
an application, might be reluctant to make generally available the database of its 
usage data. 

In a network populated by a plurality of applications that use the same 
UMS, each application A, needs to dearly define and identify those applications 
15 to which it wants to provide the information or sub-sets of information it collected 
about users 1 behavior. 

The application Aj can define policies and values of reliability of the usage 
data of other applications. For example, Ah might decide not to trust the usage 
data and users 1 preferences coming from a small, unknown, and young 
20 application firm or refuse information from application Aj because of a bad past 
experience. 

According to the present invention, that object is achieved by means of a 
method having the features set forth in the claims that follow. The invention also 
relates to a corresponding system and encompasses a media delivery network 

25 comprising such a system, as well as a computer program product loadable in 
the memory of at least one computer and comprising software code portions for 
performing the steps of the method of the invention when the product is run on a 
computer. As used herein, reference to such a computer program product is 
intended to be equivalent to reference to a computer-readable medium 

30 containing instructions for controlling a computer system to coordinate the 
performance of the method of the invention. Reference to "at least one" computer 
is obviously Intended to highlight the possibility for the arrangement of the 
invention to be implemented in a de-centralized fashion. 
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In one of its aspects, the present invention provides user modeling in 
media delivery networks, wherein a set of applications are adapted to exchange 
usage data by means of at least one user modeling server: associated with the 
user modeling server is a function for regulating exchange of usage data 
between any of a first application and a second application in said set, wherein 
the function defines: 

- whether said usage data are provided by said first application to said 
second application, and 

- a degree of trust acknowledged by said second application to the 
provided usage data. 

By trust or "degree of trust", within the context of the present invention, it 
is meant a degree, which can be expressed for example as a percentage value, 
of usage by an application of data provided by a different application. In other 
words, the degree of trust represents the extent to which an application decides 
to use the usage data available from another application. 

Preferably, the function for regulating the exchange of usage data is in the 
form of a bi-directional relationship, wherein any of the first and second 
applications is configured for accepting, refusing or negotiating the relationship. 
In a preferred embodiment, the bi-directional relationships between first and 
second applications are included in a user modeling component that calculates 
the prediction about preferences of a user by taking into account the function of 
regulating the exchange of data. 

In the arrangement described herein applications can define sharing 
policies and values of reliability, i.e., the degree of trust, of the usage data of 
other applications. In other words, a given application can clearly identify and 
define sharing rules for sharing information it owns, or a subset of it, and trust 
relationships for attributing a degree of confidence to the data the application 
receives. 

Sharing policies determine which applications will benefit from the usage 
data and feedback of a given application, and under what conditions those 
applications will have access to these data. 

Dynamic definition and management of trust relationships are allowed 

■. 

together with persistent policies to identify applications either in an extensive 
way, i.e. by listing all applications, or in an intensive way, i.e. by defining 
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automatically one or more properties that must be satisfied by all trusted 
applications, e.g. be older than 2 years or have more than 1 million users. 

According to a preferred embodiment, the present invention relates to an 
enhanced UMS wherein the registration of an application with the UMS 
5 comprises the definition of bi-directional trust relationships among applications in 
order to define: 

- permissions (and, more generally, policies) for the utilization of usage 
data by other applications; 

- a set of relationships to identify the degree of trust and/or importance of 
0 usage data provided by other applications, and how to use them for estimating 

user preferences. 

In a preferred embodiment, these rules are bi-directional in nature, 
meaning that they have to be accepted and satisfied both by the application 
providing usage data and by the application utilizing usage data. 

5 in one of its preferred embodiments, the method of providing user 

modeling according to the present invention comprises the possibility of defining 
a sort of policy for managing the exchange of values that takes into account 
"debits" and "credits". A debit is the Value* each application A| has received by 
other applications under the form of usage data contributing to the improvement 

0 of the user model estimation provided by the UMS to Aj. A credit is the Value' 
provided by Aj to other applications. 

The arrangement described herein thus provides a system where a 
provider wishing to use the user modeling service from the UMS for personalizing 
its own application, can enter in the UMS network in a controlled way. The 

5 provider has thus the possibility of listing those actors to which it provides the 
usage data and feedback generated by its own application and those actors from 
which Information Is acquired (and to which extent the information is acquired). 
This solution allows protection, in a competitive market, of the value of the 
feedback information and to differentiate a large application providers from a 

0 small application provider having shorter, less frequent sessions, with fewer 
users, and, consequently, with a small set of usage data. Therefore, the 
arrangement described herein allows different actors to share the same UMS 
while maintaining classic competition rules. 
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Brief description of the annexed drawings 

The invention will now be described, by way of example only, with reference 
to the annexed figures of drawing, wherein: 

- Fig. 1 shows the basic components of a user modeling server (UMS) 
5 arrangement as described herein, 

- Fig. 2 is a flow chart exemplary of possible operation of the arrangement of 
Fig. 1, 

- Fig. 3 is a block diagram showing the internal architecture of a UMS 
arrangement according to an embodiment of the present invention, 

10 - Fig. 4, comprising four portions designated a to d, respectively, shows 

different trust relationships according to an embodiment of the invention, 

- Figs. 5 is exemplary of how user preferences may be determined in the 
arrangement described herein, and 

- Fig. 6 shows the components of a user modeling component (UMC) 
15 comprised in a UMS according to an embodiment of the invention. 

Detailed description of preferred embodiments of the invention 

An exemplary embodiment of the arrangement described herein will now 
be detailed by referring to an improved user modeling server (UMS). 
20 In several application domains, user-adaptive systems have already 

proved to be more effective and/or usable than non-adaptive systems. Utilizing 
personalization and the underlying one-to-one paradigm is of paramount 
importance for application entities in order to be successful in today's short-lived, 
complex and competitive markets. 
25 In order to exhibit a personalized behavior, software systems rely on 

models of relevant user characteristics (e.g., interests, preferences, knowledge) 
and the acquisition and the management of these models is allotted to a 
dedicated user modeling component. 

A distinctive aspect of the user model server (UMS) described herein is 
30 dictated by the concern for the value of the pieces of information that an 
application notifies to the central user modeling server. 

User-adaptive or personalized applications generally aim at anticipating 
the needs of each individual user, while adapting to these needs by interacting 
with the user. In order to be able to individually adapt to the current user, user- 
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adaptive applications rely on information about Individ ual characteristics of each 
user and characteristics of the user groups to which a user belongs. 

This information (or usage data) is stored in so-called user profiles. 
Typical information about users includes: 
5 - user data: demographic data, user knowledge, skills, capabilities, 

interests, preferences, goals and plans 

• feedback data: observable usage (e.g., selective actions and ratings) 
and usage regularities (e.g., usage frequency and action sequences); and 

- environment data: software and hardware environment and the user's 
0 current location, for example. 

This information is individually acquired for, and associated with, each 
user. The user profile persists across different user sessions and a user is linked 
to his or her user model at the beginning of each session. 

While user data usually represent static Information provided by the user 
5 for example filling in a registration form, feedback data are a sequence of 
observable/observed pieces of information, where the observations can be made 
by the user-adaptive application. 

The present description will refer to information collected by a user- 
adaptive application also as "feedback", which comprises thus a reaction from the 
0 user to the proposed solution (i.e., the feedback data) and optionally also the 
user data. 

Conversely, a user model is a process that, starting from the whole or part 
of the information (the user profile), will generate context-based predictions on 
user interests and/or preferences. 
5 Figure 1 shows the generic architecture that allows a UMS as described 

herein to support reuse of user models over a series of adaptive systems. 

From a static point of view, the global system is comprised of: 

- a UMS, which is a server providing the user modeling functionality, and 

- a set of applications A 1t ..., A*: these are generally user-adaptive or 
0 personalized applications such as services, content providers, e-commerce sites, 

which take advantage from the UMS. 

In a preferred embodiment, the system will include at least one server 
UMS providing the user modeling service and a plurality of application servers 
Ai\ .., An 1 where the applications A-,,..., An or part of them can run. These 
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application servers are connected through a network to a user terminal UT that 

sends the required information. 

The arrows in Fig. 1 indicate the data flows between the different actors in 

the global scenario. A generic user will request a personalized service from the 
5 application, and the application will request a specific user model from the server 

UMS. After user interaction with the service, the application will notify to the 

server UMS the usage data. 

The sequence of operations and steps performed by the different 

components in the system according to an embodiment of the invention is shown 
0 in Fig. 2. 

It will be assumed that a user U wants to access a personalized service 
offered by an application Aj in the domain Oi (step 100). For instance, a user 
John Doe requests a list of suggestions from a large "Librarian" site (Aj) in the 
literature-and-book domain(Oj). 

5 In a step 102 the user fills in an appropriate box with his usemame u. 

This may occur in compliance with requirements for secrecy in user- 
adaptive systems in order to guarantee the anonymity of both users and user 
modeling servers. For instance, pseudonymous identification (see, e.g. A. Kobsa 
et al.: "Privacy Through Pseudonimity in User Adaptive Systems' 1 . ACM 

0 Transactions on Internet Technology, Vol. 3, No, 2, May 2003, pages 149-183) 
may be resorted to: the user initially chooses a unique but otherwise uncontrolled 
pseudonym u which he will also employ in subsequent sessions. 

Pseudonimity may represent a sensible compromise between privacy 
demands and the requirements of the user modeling: the arrangement disclosed 

5 herein can thus be adapted to operate in full compliance with existing laws and 
regulations in the area of protection of privacy. 

In order to build the appropriate personalized psge, in a step 104 the 
application A, requests to the core component UMS the interests and preferences 
of the user with pseudonym (usemame) u. Because of this request, in a step 106, 

0 the server UMS starts an inference algorithm that will be detailed in the following. 
In other words, UMS implements an inference process in order to build the user 
model associated to the given pseudonym and, specifically, it calculates the 
preferences of the user indicated as u in the domain Oj. 

In the exemplary embodiment described herein, the server UMS 

5 generates the preferences of the user "mickeymouse" (the usemame u chosen 
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by John Doe) in the literature-and-book domain taking into account all the 
indications about the past behavior of mickeymouse in previous sessions in the 
"Librarian" site or in another site belonging to the literature-and-book domain or to 
other domains that likely affect literature-and-book preferences. 

5 Based on the indicated interests -e.g., mickeymouse likes science fiction - 

and preferences - e.g. mickeymouse likes Asimov and does not like Tom Clancy - 
as provided by the server UMS in a step 108, the application A| is able to 
generate a personalized service (e.g., a catalogue of suggested books to buy). 
By way of example, the application sorts all the available items in its own content 

0 description database; this occurs in a manner that is known per se and leads to 
generating a personal catalogue fisting those items that better suit the user 
model. 

In a step 110 the user U (or u) makes use of the personalized services 
offered by the application A< navigating in the pages, selecting some items, 
5 requesting more information, buying some objects, and so on. Each of these 
actions are monitored and collected by the application A| in a step 112. 

Once the user session is completed, or at a fixed deadline, in a step 1 14 
the application A* notifies all the "feedbacks" to the server UMS. The feedbacks 
that an application generally notifies are; the time spending navigating a page, 
0 the selection of some items, the request for additional information, putting of an 
object into the basket or cart, the explicit rating about an item and so on. 

It is assumed for example that 

- the server UMS is a central user model server offering modeling 
services owned by different actors who are in competition between each other, 

5 and 

- in a similar domain such as the previous literature-and-book domain, two 
different service providers affiliate to the server UMS. The former one being a 
large and wide provider such as "Librarian", while the latter is a small district 
library such as Tiny-book" that, starting today, will offer a small online catalogue. 

0 The amount of feedbacks from the large company will inevitably be much 

larger and perhaps more valuable than the feedbacks provided by the small 
company. This means that the large provider will probably be reluctant to make 
available its database of usage data and pieces of business information, as this 
would provide an additional value also to its competitors. 
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Therefore, there are two different aspects that a valid candidate UMS 
should take into account 

A first problem refers to the reliability of usage data: how much an 
application will trust the feedback provided by other actors and/or competitors. 
5 Another important aspect is that account should be taken of the possibility 

for an application to specify the set of applications that have the permission to 
access and use its own usage data or a sub-set of it. 

Coming back to the example of "Librarian" and "Tiny-book", due to the 
high value of its feedbacks, "Librarian" will expectedly wish to forbid access to its 
0 usage data for all the competitors except for example for a single book seller 
which it has a strict and trusted relationship with. 

In a preferred embodiment, bi-directional control over the feedbacks can 
be implemented by the internal architecture of the server UMS shown in Fig. 3. In 
Fig. 3, an application Ai can access the UMS through an application interface 60, 
5 which is configured for exchanging feedbacks and requests for preferences and 
which comprises an associated protocol which controls the communication 
between the UMS and the application. The main components of the UMS are: 

- a first database 10 containing the static information about the registered 
usersand their profiles, for example data as age, gender, addresses, and explicit 

0 preferences (i.e., the user data); 

- a second database 40, comprising a feedback database that collects the 
feedbacks about users' behavior, each feedback is coupled with its source, that is 
to say the application that generated it This database thus comprises the 
feedback data related to the users; 

5 - a third database 30 comprising a registration rule database containing 

the rules that regulate and control the relationships between the applications and 
the way for using, in a specific application, the feedbacks provided by other 
applications; and 

- a user modeling component (UMC) 50 acting as the core of the system 
0 that, starting from the profile of the user and the available feedbacks and 

weighting the feedbacks according to the rules contained in database 30, 
calculates the preferences of a user in a specific domain. 

Preferably, the UMS comprises a fourth database 20 comprising an 
application provider database wherein each application is described by an 



WO 2005/059782 



PCT/EP2003/014116 



12 

appropriate schema (for example: name, affiliation, nationality, application 
domain, age of presence on the web). 

The UMC 50 will be described in more detail with reference to Fig. 6. 
Although in the embodiment illustrated in Fig. 3, the first database 10 
5 containing the static information over the users and their profile and the second 
database 30 containing the dynamic information (i.e. feedbacks relating to users' 
behavior) are two separate databases, a single database containing static 
information and dynamic information can be envisaged in the UMS. 

When a new content provider subscribes its application to the server 
10 UMS, a registration phase begins. 

This phase may involve a direct negotiation between different people or 
could be achieved via appropriate web forms. Often, different applications utilize 
different criteria to describe/classify the items or a different model to describe the 
users. In that case, the server UMS may comprise the function of mapping 
15 between the different descriptions/classes so that uniformity between the 
classifications/description is achieved in the system. 

The possible trust relationships among applications can be represented 
with a graph, as shown in the examples schematically illustrated in Figs. 4a to 4d. 
Essentially, a graph consists of a set of vertices (here the different applications 
20 A 1f ..., An) and a set of edges which connect two vertices in the graph; in the 
present arrangement, an edge will represent a trust relationship. The designation 
'depth' will denote the number of edges between two vertices, in the present 
embodiment the possibility exists of associating to an edge a numerical value, 
indicated as trust degree', which indicates a percentage of trust, a weight to 
25 assign to the feedbacks collected from the vertices. 

In accordance with the general graphical representation of Fig. 4a an 
application A 1 wants to register in the UMS in which applications A 2 ,.... T A 7 are 
registered and are linked one another by certain rules. When Ai registers, the 
other registered applications are linked through certain trust relationships, as 
30 those shown in Fig. 4a as an example. A 2 has indicated a certain trust 
relationship with As, A 7 and A», which is turn has indicated a trust relationship 
with Aa. A3 and Ae have a mutual trust relationship and A3 trusts A4, but A4 does 
not trust A3, as illustrated from the direction of the arrows. Some examples of 
trust relationships that A1 can negotiate are listed as follows. 
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A n indicates a 100% trust relationship with the vertex/application A 2 and 
depth equal to zero: in determining the preferences of a user u f the UMC will 
consider the feedbacks from A 2 and A t (Fig. 4b). 

Ai indicates a 100% trust relationship with vertex/application A 2 and depth 
5 equal to 1 under A 2 (i.e., applications that are trusted by A 2 ) with trust degree 
100% with the exception of A 7l which is not trusted: in determining the 
preferences of a user u, the UMC will consider the feedbacks from Ai, Aw 2f A 5 and 
A4 but not from A 7 (Fig. 4c). 

Ai indicates a 100% trust relationship with vertex/application A 2 and a 
10 depth equal to 1 under A 2 with trust degree 60% (i.e., with applications and A 5 ) 
and a 30% trust relationship with A 7 : in determining the preferences of a user u, 
the UMC will consider as globally trusted the feedbacks from A 2 , it gives a minor 
weight to the indications from A4 and A5 and still a little smaller weig ht to the 
feedbacks from A 7 (Fig. 4d). 

15 

In order to protect the value of the feedbacks, the addressee of the trust 
relationship will approve, refuse or refine the request (for example req uiring an 
appropriate remuneration). 

In addition to the possibility of expressing a list and the degrees of trust 

20 with the other actors, in the registration phase an application can indicate 
possible restrictions in the use of its own usage data. This means that the generic 
application Ai could decide to send the complete or a partial set of its usage data 
to the UMS, but Ai has the power to allow their use for the calculation of 
preferences to Aj and to forbid their use to A*. 

25 In the exemplary arrangement considered, "Librarian" could for instance 

deny the access and use of its usage data to "Big-Book" because the competition 
is too high for sharing usage knowledge, but "Librarian" could allow to provide 
information to small and quiet business actors such as "Tiny-book". 

A negotiation process can start each time a new application Aj comes to 

30 the system UMS and can be comprised of the following steps: 

- Aj negotiates the sharing rules with other applications (A^ ... Ai_ l4 A^i, ... 
A^, indicating the set of A's that can access its usage data, and 

- A, negotiates the trust relationships with A k 's in which it is interested (Aj 
negotiates because A* could accept, refuse or change/refine the request). 



WO 2005/059782 



PCT/EP2003/014116 



14 

Although reference has been made to the situation in which a new 
application (never previously registered in the system) comes into the system, it 
is to be understood that rules and relationships may be modified at any time, e.g., 
after registration of the new application. 
5 This negotiation process is not always a direct communication between 

people: such a process could become too time-consuming as the number of 
actors in the system UMS increases. 

According to a preferred embodiment, the description of each application 
managed in the application provider database 20 (Fig. 3), a generic application A, 
10 can define a set of rules and policies by an automatic negotiation process. 

For instance: 

- A, defines a 100% trust relationship with each application in the 
literature-and-book domain; 

- A defines a 75% trust relationship with each application that has been 
1 5 present on the web for at least three years; 

- Aj refuses the utilization of its usage data to young applications (age on 
the web < 3 years) and to national business actors; and 

- Ai defines a 70% trust relationship with "Librarian" and "Big-Book". 
Especially in an open environment wherein new applications subscribe to 

20 the UMS in whatever moment, policy-based management can be adopted as a 
way for defining sharing rules and trust relationships. A policy-based 
management is often used in systems where flexibility is required as users, 
services and access rights change frequently. 

One example of policy language is disclosed in Kagal L. et al.: a A Policy 
25 Language for a Pervasive Computing Environment, published in IEEE 4 th 
International Workshop on Policies for Distributed Systems and Networks (2003), 
which describes a language based on "deontic" concepts such as rights, 
prohibitions, obligations and dispensations to perform actions. 

After the completion of the registration phase, when a request from an 
30 application A* arrives to the UMS, the calculation in the UMC is carried out as 
schematically illustrated in Fig. 5. 

Specifically, in a step 200 the application A, requests the user preferences 
of a pseudonymous user u. 

As a result of this, in a step 202, the UMC retrieves the user model for u, 
35 while retrieving in a step 204 the feedbacks concerning the same user. 
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Additionally, in a step 206, the UMC retrieves the registration rules relative to 
application A|. 

Based on the outcomes of steps 204 and 206, in a step 208, the UMC 
makes the appropriate inferences generating predictions about preferences. 
5 Finally, in a step 210, based on the outcomes of steps 202 and 208, the 

UMC merges the dynamic profile with the static profile of the user u. 

Specifically, in the step 208, the UMC retrieves all the available feedbacks 
concerning the user u and it calculates the appropriate inferences by rejecting the 
feedbacks from Ak if no trust relationship exists between A| and A* or weighing its 
10 feedbacks with a certain trust factor. 

At the end of the step 208, the component UMC has generated the 
preferences for a specific user; these preferences values corresponding to the 
dynamic behavior of the user are integrated and merged in the step 210 
(according to well known techniques) with the static information contained in the 
15 user profile of the selected user. 

Each access to the UMS is generally treated as a request that is discrete, 
i.e. , independent from former and subsequent accesses. 

In a real implementation of the system, it may not be practical to save and 
analyze the log of behaviors of all users in all the registered applications every 
20 time a new request is received. This is due to the high level of disk space and 
computer memory required. A compressed, optimized and scalable way for 
managing the usage data can be preferred. A possible way of solving this issue is 
to save only the user information in an aggregated manner and not the entire set 
of all the collected feedback. This may occur, for example, by storing the results 
25 in terms of preferences resulting from inference process performed on the initial 
set of feedbacks. In addition, it is possible to implement some cache mechanisms 
that store, for a certain time, the outcome of a certain number of requests of user 
preferences. 

Figure 6 depicts schematically a detailed architecture of a User Modeling 
30 Component (UMC) included in the UMS according to a preferred embodiment of 
the present invention. 

Specifically, A 1f A 2> A3,..., An are n registered applications in the server 
UMS and UMMfA^, UMM(A 2 ), .... UMM(An), are user modeling modules (UMMs) 

relative to applications A^ A 2 An, respectively. The UMMs correspond to 

35 software components implementing known user modeling techniques. 
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The UMC of Fig. 6 is comprised o*f a software merging component, MC. 
When the server is notified by a set of usage data performed by the user u in the 
application A(, these feedbacks are sent to the UMM(Aj) corresponding to the 
application A| and used in a known manner (by way of example, using 
5 collaborative filtering algorithms or Bayesisn networks). Information about user u 
collected by each application Ar is indicated in Fig. 6 with ud(A*). 

When an application A x requests the preferences, referred to as the 
prediction value of preference, PfA^u.O*) , of the user u in the domain O x (for 
example "Librarian" wants to know the preferences of mickeymouse in the 

10 literature-and-book domain) the merge component MC requests from the different 
components UMM(Aj), with j=1,...,n the respective prediction values P(A jr u, Oj) 

where u designates the user and Oj (with j=1 n) denotes the specific domain. 

Each UMM(Aj) is thus able to generate a prediction value corresponding to the 
user u into a specific domain. 

15 The task of the merge component MC is to calculate the overall user 

preferences in the domain O x by taking into account: 

- the ontology that relates the domains that may influence to the 
requested domain O x (for example the preferences in the literature-and-book 
domain requested from "Librarian" could be influenced by the music preferences 

20 provided by the application "BachNew" according to a mapping table between 
different ontologies and in a way known p&r se). An ontology is generally defined 
as a logical theory which gives an explicit representation of a conceptualization. It 
allows to represent, in a more or less formal way, concepts of a domain of 
concern and their relations. The ontology includes relationships between terms in 

25 two or more different topics, e.g., similar, broader, narrower; 

- the applications that A* is trusting (for example "Librarian" trusts 100% 
the preferences inferred by "BachNew" but only 50% the preferences provided by 
other applications younger than, say, two years In the music domain); and 

- the applications that have accepted to share their usage data with A x (if 
30 "Big-Book" has refused the usage data request from "Librarian", the merge 

component MC cannot use, in its calculations, the preferences provided by "Big- 
Book"). 

Bi-directional relationships can be developed between two applications. 
The term "bi-directional" is intended to highlight the fact that the relationships in 
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question typically involves two actors, both playing an active role (namely 
accepting, refusing or negotiating the relationship). 
Such relationships enable an application to: 

- define a policy for the utilization of its own usage data by other 
5 applications; and 

- define a set of relationships managing the trust of usage data provided 
by other applications in the calculation and inference of user preferences. 

The UMC will thus provide the application Ax with the preference value 
P(A Xl u,O x ) that has being weighted according to the registration rules relative to 

0 the applications. 

By monitoring all the notifications of usage data and the requests of user 
preferences from each application, the server UMS has a clear picture of the 
activities of each application in the system and the difference between the value 
of the provided information and the value associated to the requests. 

5 In a further embodiment, a mechanism in which a value or a value 

function can be explicitly assigned to the exchanged pieces of information may 
be added to the UMS in order to improve the maintenance of the system balance. 
An application may be encouraged to actively participate in the system by 
notifying its feedbacks as an alternative to solve its debit in some ways, e.g. 

0 through payment. It could also be possible that the system may not allow an 
application just to sends requests and never provide usage data. This 
mechanism can be also referred to as mechanism of "debits" and "credits". 

By way of further explanation, reference can be made to a system 
including: 

5 - "Librarian", selling books and records, 

- "Big-book" selling books, 

- "GoodDisco", a small record store, and 

- "Tiny-book", a small book store. 

It will also be assumed that, at the end of the registration phase of the 
0 applications listed in the foregoing, the following trust relationships (i.e. trust 
acknowledged to the other applications) have been established: 



Trust 





Librarian 


Big-book 


GoodDisco 


Tiny-book 


Librarian. 


100% 


95% 


2% 


1% 


Big-book 


95% 


100% 


3% 


5% 
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Good Disco 


100% 


100% 


100% 


60% 


Tiny-book 


97% 


100% 


80% 


100% 



The table in question is to be read as follows: by assuming that the 
applications accept to provide their user information, GoodDisco will 100% trust 
indications from Librarian, 100% those from Big-book and only 60% thos^ 
5 provided by Tiny-book. 



Availability to provide Indications (sharing rules) 





Librarian 


Big-book 


GoodDisco 


Tiny-book 


Librarian 




YES 


NO 


YES 


Big-book 


YES 




YES 


NO 


GoodDisco 


YES 


NO 




YES 


Tiny-book 


NO 


YES 


YES 





The table in question is to be read as follows: Big-book has expressed its 
10 availability to provide its user indications to Librarian and GoodDisco but has 
denied transmission of its data to Tiny-book. This could apply also for a set of 
data. 

A user mickeymouse is now assumed to log into the Big-book website and 
require a personalized service comprising e.g. browsing a catalogue. According 
15 to the prior art of personalization and information retrieval, a personalized 
catalogue includes a list of items (such as books) that are held to be of interest: 
for the user. 

The process for determining the preferences operates as follows. 
The system searches (in the Registration Rule Database) the list of those 
20 applications that have accepted to provide Big-book their user indications. In the 
example considered here the list includes {Librarian, Tiny-book} while GoodDisco 
is not included in this list. 

The system then requests from Big-book and ail other applications in the 
previous list the preference values that the respective user modeling modules 
25 (UMMs) are in a position to determine. In other words, the system sends out a 
request for preference values for the books for the user mickeymouse to the 
Librarian UMM, the Big-book UMM and the Tiny-book UMM. 
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The system waits for the responses from the three UMMs questioned and 
collects the values returned. For instance, one may assume that the "ontologies" 
used in the three applications are identical and the responses provided those 
listed in the following table. 

5 





Big-book 


Librarian 


Tiny-book 


Horror 


10% 


15% 


30% 


Fantasy 


5% 


10% 


30% 


Thrillers 


50% 


45% 


10% 


Romance 


15% 


20% 


20% 


Adventure 


20% 


10% 


10% 


Total 


100% 


100% 


100% 



The system determines the final value for the preference function for the 
books for the user mickeymouse as. requested by the application Big-book. This 
is done by weighing the contributions from the various applications as a function 
10 of the trust values expressed by Big-book in their regard (see the first table 
above). 

This result may be achieved as a weighted arithmetic average, such as: 

P(horror)=((1 00x1 0)+(95x15)+(5x30))/ (100+95+5) = 12.88 
15 P(fantasy)=((1 00x5)+(95x1 0)+(5x30)) / (1 00+95+5) = 8 

P(thrillers)=((100x50)+(95x45)+(5x10))/ (100+95+5) = 46.63 
P(romance)=((100x15)+(95x20)+(5x20)) / (100+95+5) = 17.5 
P(adventure)=((100x20)+(95x10)+(5x10))/ (100+95+5) = 15 

20 Alternatively, the final value of the preference function can be based on 

more complex algorithms, known per se in the art. 

The system sends to the requesting application, namely Big-book, the 
preference values as determined. After receiving these values, Big-book will use 
them as deemed best in order to personalize its service based on known 
25 techniques, e.g. by presenting in its home page, over a total of 10 books 
suggested, five thrillers, two romance stories, two adventure books and one 
horror book. 
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The sequence outlined above is deliberately simplified with respect to the 
real implementation and deployment. In fact it is possible to contemplate and 
manage such situations where different applications may manage different 
classifications and ontologies. Under these circumstances, the need arises of 
5 taking into account mapping between ontologies (by acknowledging that, e.g. 
"thrillers" for Tiny-book corresponds to "police stories* for Librarian). 

In a preferred embodiment, one may consider that in certain conditions a 
mechanism of debits and credits is set up by property valuating the information 
exchanged. The system of debits and credits is managed by the UMS. The UMS 
10 collects the values that each application gives to its information and weights to 
which extent an application shares its information and to which extent the same 
application requests information. 

In the case considered it may well happen that Librarian may state that it 
is reluctant to provide its user indications to other applications. The possibility 
15 exists for any application to label its user indications with respective values. For 
instance: 

- Librarian assigns a value 50 to its user information; 

- Big-book assigns a value 45 to its user information; 

- GoodDisco assigns a value 10 to its user information; and 
20 - Tiny-book assigns a value 5 to its user information. 

In that case, in addition to the operations already described, the system 
will maintain a sort of virtual account for each application: in the case considered, 
having received information from both Librarian and Tiny-book, Big-book will 
have a debit against Librarian of 50 units and a debit of 5 units against Tiny-book. 
25 Conversely, Librarian will have a credit of 50 units against Big-book. 

The related counters are continuously updated at each request for 
preference values and permit at each instant to evaluate the state of balance of 
the system, while possibly requesting compensations or compensative actions 
when remarkable debits or credits have accrued. 
30 Those of skill in the art will promptly appreciate that the various elements 

described in the foregoing can be hosted on different servers and machines. 
Specifically the user can manage different terminals and equipment comprising a 
personal computer, a hand-held computer or a telephone. Moreover, a preferred 
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embodiment provides for the UMS being managed by a mobile phone operator 
that offers user modeling to several registered applications. 

The user modelling server UMS could be a distributed system, hosted by 
a number of servers. 

5 Specifically, the user modelling component of an application, UMM(A,) 

(see Fig. 6) can be hosted in the system or reside on a different server or 
machine. This will also facilitate integration with previously existing (legacy) user 
modelling systems. 

The server(s) UMS could be hosted by telecommunication operators, the 
10 clients that request personalized applications could be PDA or mobile phones 
and the network that links the different peers could be an Internet connection, a 
GPRS and/orUMTS network or the like. 

The operator that hosts the system could be itself an application and it 
could take advantage of the complete and precise user models in order to 
15 personalize its services (as a matter of example, a mobile operator could 
personalize advertisements or applications) 

As an example, a possible configuration of a UMS of the kind described 
herein might include the following elements: 

- at least one central server hosting the central system; preferably the 
20 server in question is a high level server equipped with e.g. a Windows 2000™ 

server operating system and an application server supporting web services (e.g. 
Apache Tomcat™) within a Java™ (e.g. 1.4) execution environment as the 
natural language for distributed programming and having installed thereon a 
relational database (e.g. Microsoft Access™ or Oracle™ or the like); 

25 - one or more peripheral servers having installed thereon the various 

UMMs (such servers can also be installed with the various application providers); 
these are typically medium level servers equipped with e.g. a Windows 2000™ 
Server operating system and an application server supporting web services (e.g. 
Apache Tomcat™) within a Java (e.g. 1.4) execution environment as the natural 

30 language for distributed programming, and 

- a network infrastructure connecting the central server with the various 
peripheral servers: this may simply be a fixed or mobile telephone network. 

The preference values provided by the UMS could be used by the 
applications in different scenarios such as e.g. the personalization of a list of 
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items to be sold, the personal adaptation of a multimedia content, suggestions for 
some proactive actions. 

in addition to the user modeling functionality, the system could also play 
the role of authentication server and repository of user information (age, address, 
5 credit card details), and/or be used in a big organization where different 
departments may have different access and trust policies. 

The system may also manage the overall balance through a mechanism 
of debits and credits, and, thanks to the design of the relationships through rules 
and policies, allow the model to be scrutinized from the user point of view, while 
10 also allowing the user to select his/her user model to be kept secret (wholly or 
partly) and disclosed only to selected, registered applications. 

Of course, without prejudice to the underlying principle of the invention, 
the details and embodiments may vary, also significantly, with respect to what 
has been described, by way of example only, without departing from the scope of 
15 the invention as defined in the claims that follow. 



